File naming for Phoenix data products
Data product file names are formatted to convey information about the product content. The file naming convention used for Phoenix products is given below.
mission specific
Phoenix data products follow a general file naming scheme, with an instrument-specific portion within the file name. Image mosaic file naming details are provided at the bottom of this page.
Phoenix data product file names
01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
INST | EPOCH | SOL | PROD | INSTRUMENT SPECIFIC | WHO | VER | . | EXT |
INSTRUMENT | 01 |
Instrument identifier, as shown in the table below.
|
||||||||||||||||||||||||||||
EPOCH | 02 |
Mission source/epoch.
|
||||||||||||||||||||||||||||
SOL | 03-05 |
If Epoch is “S”, specifies number of Solar days since first full day on Mars. Landing day is Sol one (“001”). However, if Epoch is “T” or “C”, specifies day-of-year (ERT or SCET). Example value is “004”. |
||||||||||||||||||||||||||||
PRODUCT | 06-08 |
Product identifier. Refer to Phoenix data product types for a list of possible values. Note that for TEGA, the value in this position will be either "EDR" or "RDR". The instrument-specific value contains the specific product type or engineering parameter value. |
||||||||||||||||||||||||||||
INSTRUMENT SPECIFIC | 09-25 |
Values specific to particular instrument data and product types. The details are given in tables on this page, easily found by follow these links: |
||||||||||||||||||||||||||||
PRODUCER | 26 |
Identifier for the institution/team that created the product.
|
||||||||||||||||||||||||||||
VERSION | 27 |
Version identifier providing uniqueness for book keeping. The valid values, in their progression, are as follows: Range 1 thru 9 - “1”, “2”… “9” Range 10 thru 35 - “A”, “B” …“Z”
For images, the Version number increments by one whenever an otherwise-identical filename would be produced, independent of the Special field. Thus, even though the Special field may change, the Version number continues to increment by one over the previous Version. This allows the "best" Version of a product to be determined - irrespective of what special processing was done to achieve it - by simply looking for the highest Version number. The following examples show how the Version field increments independently of the Special field thru a progression of RDR processing for the same SCLK product:
|
||||||||||||||||||||||||||||
. | 28 | Separator; always a period. | ||||||||||||||||||||||||||||
EXT | 29-31 |
Product type extension.
|
Instrument specific: image edrs and single-frame rdrs
09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 |
SCLK | SPEC | ACTIVITY ID | PAYLOAD | EYE | FILT |
Instrument specific: MECA non-imaging EDRs
09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 |
_ | REVISION | _ | RECORD LENGTH |
OPS TOKEN |
_ | 09 |
Separator, always an underscore. |
REVISION | 10-11 |
EDR revision number, 0-255, represented at a 2-digit Hex value. |
_ | 12 |
Separator, always an underscore. |
RECORD LENGTH | 13-17 |
Length of records represented as a 5-digit Hex value. |
OPS TOKEN | 18-25 |
Ops Token Token value represented as an 8-digit Hex value. |
Instrument specific: MET EDRs
Instrument specific: TEGA engineering files
09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 |
_ | ENG PARAM | _ | DATE | _ |
_ | 09 | Separator, always an underscore. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ENG PARAM | 10-15 |
Engineering parameter abbreviation.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
_ | 16 |
Separator, always an underscore. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DATE |
17-24 | UTC date of turn on for sol of interest, formatted as yyyymmdd. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
_ | 25 | Separator, always an underscore. |
Instrument specific: TEGA non-engineering files
09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 |
_ | PROD | _ | DATE | __ |
_ | 09 | Separator, always an underscore. |
PROD | 10-12 |
Product identifier. Refer to Phoenix data product types for a list of possible values. |
_ | 13 |
Separator, always an underscore. |
DATE |
14-23 | UTC date of turn on for sol of interest, formatted as yyyy_mm_dd. |
_ | 24-25 | Separator, always two underscores. |
Image mosaic file names
01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
INST1 | INST2 | SOL | PRODUCT | _ | PROJ | GEOM | FRAME | BRT | ACT | PAY | SPEC | EYE | FILT | WHO | VER | . | EXT |
INST1 | 01 |
Identifier of "primary" instrument.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
INST2 | 02 |
Identifier of "secondary" instrument.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SOL | 03-05 |
Specifies number of Solar days since first full day on Mars. Landing day is Sol one ("001"). This field is defined as the primary Sol for this mosaic. For most (and all automatically-produced) products, this is extracted from the input image with the earliest (i.e. lowest) SCLK. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PRODUCT | 06-08 |
Product identifier. Refer to Phoenix data product types for a list of possible values. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
_ | 09 |
Separator, always an underscore. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PROJECTION | 10-12 |
Projection type. Indicates the projection or perspective of the product.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GEOMETRY | 13 |
Specifies Geometry Correction flag. Indicates what kind of geometric correction has been applied to data. If multiple types of corrections were applied, then the highest-level (in the table below) value is used.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
FRAME | 14 |
Specifies coordinate frame in which the mosaic is generated. Note that the instance of frames (e.g. Payload) is not specified and must be obtained from label.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BRT | 15 |
Specifies Brightness Correction flag indicating what kind of brightness (radiometric) seam-matching process has been applied to the mosaic. Brightness correction is a seam-matching process done on top of radiometric correction in order to make the mosaic look better; some radiometric accuracy is lost in the process. If multiple types of correction are done, the highest-level (last in the table) value is used. NOTE: If any kind of brightness matching is applied, the inputs must first be radiometrically corrected. This is stated explicitly in the filename by <prod>, or implicitly if <prod> is not a radiometrically-corrected type, meaning that MIPLRAD has been used.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ACTIVITY ID | 16-19 |
Activity ID as extracted from round-trip accountability Token. Valid values are assigned at planning time by PSI tool. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PAYLOAD | 20 |
Identifier of Payload type as extracted from round-trip accountability Token. 1 Hex character representing 4 bits of the 32-bit Token based on a bit lookup, which follows:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SPECIAL PROCESSING |
21 |
Special processing designator to be defined later. This character is used to indicate off-nominal or special processing of the image. Examples might be use of different correlation parameters, special stretches to eliminate shadows, reprocessing with different camera pointing, etc. The meaning of any individual character in this field will be defined on an ad-hoc basis as needed during the mission. Within one Activity ID, the character will be used consistently, so this field can be used to group together all derived products resulting in one kind of special processing. An attempt will be made to maintain consistency across different Activity ID's as well, but this may not always be possible; thus the meaning of characters may change across different Activity ID's. A text file will be maintained containing all special processing designators that are used, the Activity ID's they relate to, and a description of the special processing that was done. This file will be included in the PDS archive. Valid values are:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
EYE | 22 |
Camera eye
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
FILTER | 23-25 |
Specifies 3 spectral filter positions, LED settings, or color space components. Additional values were planned in the case of color mosaics and mosaics with more than three bands. However, such mosaics were never archived. Refer to the camera EDR and RDR Software Interface Specification (SIS) document for the full description. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PRODUCER | 26 |
Identifier for the institution/team that created the product.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VERSION | 27 |
Version identifier providing uniqueness for book keeping. The valid values, in their progression, are as follows: Range 1 thru 9 - “1”, “2”… “9” Range 10 thru 35 - “A”, “B” …“Z”
For images, the Version number increments by one whenever an otherwise-identical filename would be produced, independent of the Special field. Thus, even though the Special field may change, the Version number continues to increment by one over the previous Version. This allows the "best" Version of a product to be determined - irrespective of what special processing was done to achieve it - by simply looking for the highest Version number. The following examples show how the Version field increments independently of the Special field thru a progression of RDR processing for the same SCLK product:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
. | 28 | Separator; always a period. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
EXT | 29-31 |
Product type extension.
|
see also